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Abstract. We present a correctness proof for a basic file system imple- 
mentation. This implementation contains key elements of standard Unix 
file systems such as inodes and fixed-size disk blocks. We prove the im- 
plementation correct by establishing a simulation relation between the 
specification of the file system (which models the file system as an ab- 
stract map from file names to sequences of bytes) and its implementation 
(which uses fixed-size disk blocks to store the contents of the files). 

We used the Athena proof checker to represent and validate our proof. 
Our experience indicates that Athena’s use of block-structured natural 
deduction, support for structural induction and proof abstraction, and 
seamless connection with high-performance automated theorem provers 
were essential to our ability to successfully manage a proof of this size. 
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1 Introduction 


In this paper we explore the challenges of verifying the core operations of a stan- 
dard Unix file system [20, 16]. We formalize the specification of the file system as 
a map from file names to sequences of bytes, then formalize an implementation 
that uses such standard file system data structures as inodes and fixed-sized disk 
blocks. We verify the correctness of the implementation by proving the existence 
of a simulation relation between the specification and the implementation. 

The proof is expressed and checked in Athena, an interactive theorem-proving 
environment based on denotational proof languages (DPLs [3]) for first-order 
logic with sorts and polymorphism. Athena uses a Fitch-style natural deduction 
calculus, formalized via the abstraction of assumption bases. High-level idioms 
that are frequently encountered in common mathematical reasoning (such as 
“pick any x and y ---” or “assume P in ---”) are directly available to the user. 
Athena also includes a higher-order functional language in the style of Scheme 
and ML and offers flexible mechanisms for expressing proof-search algorithms 
in a trusted manner (akin to the “tactics” and “tacticals” of LCF-like systems 
such as HOL [11]}). 

The proof comprises 283 lemmas and theorems, and took 1.5 person-months 
of full-time work to complete. It consists of roughly 5,000 lines of Athena code, 
for an average of about 18 lines per lemma. It takes about 9 minutes to check on 
a high-end Pentium, for an average of 1.9 seconds per lemma. Athena seamlessly 
integrates cutting-edge automated theorem provers (ATPs) such as Vampire [21] 
and Spass [22] to mechanically prove tedious steps, leaving the user to focus on 
the interesting parts of the proof. Athena invokes Vampire and Spass over 2,000 
times during the course of the proof. That the proof is still several thousand 
lines long reflects the sheer size of the problem. For instance, we needed to prove 
12 invariants and there are 10 state-transforming operations, which translates 
to 120 lemmas for each invariant /operation pair (I, f), each guaranteeing that 
f preserves I. Most of these lemmas are non-trivial; many require induction, 
and several require a number of other auxiliary lemmas. Further complicating 
matters is the fact that we can show that some of these invariants are preserved 
only if we assume that certain other invariants hold. In these cases we must 
consider simultaneously the conjunction of several invariants. The resulting for- 
mulas are several pages long and have dozens of quantified variables. We believe 
that Athena’s combination of natural deduction, versatile mechanisms for proof 
abstraction, and seamless incorporation of very efficient ATPs were crucial to 
our ability to successfully complete a proof effort of this scale. 

To place our results in a broader context, consider that organizations rely 
on storage systems in general and file systems in particular to store critical 
persistent data. Because errors can cause the file system to lose this data, it is 
important for the implementation to be correct. The standard wisdom is that 
core system components such as file systems will always remain beyond the 
reach of full correctness proofs, leaving extensive testing—and the possibility 
of undetected residual errors—as the only option. Our results, however, suggest 
that correctness proofs for crucial system components (especially for the key 
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algorithms and data structures at the heart of such components) may very well 
be within reach. 

The remainder of the paper is structured as follows. Section 2 informally 
describes a simplified file system. Section 3 presents an abstract specification of 
the file system. This specification hides the complexity of implementation-specific 
data structures such as inodes and data blocks by representing files simply as in- 
dexable sequences of bytes. Section 4 presents our model of the implementation 
of the file system. This implementation contains many more details, e.g., the 
mapping from file names to inodes, as well as the representation of file contents 
using sequences of non-contiguous data blocks that are dynamically allocated on 
the disk. Section 5 presents the statement of the correctness criterion. This crite- 
rion uses an abstraction function [15] that maps the state of the implementation 
to the state of the specification. Section 5 also sketches out the overall strategy of 
the proof. Section 6 and Section 7 address the key role that invariants and proof 
tactics played in this project. Section 8 gives a flavor of our correctness proof by 
presenting a proof of a frame-condition lemma. Section 9 presents related work, 
and Section 10 concludes. The Appendix contains a description of the relevant 
parts of certain Athena libraries that were used in this project. 


2 A Simple File System 


In this section we describe the high-level structure of a simple file system. In 
Section 4 we present a formal model of such a file system. 

In our file system the physical media is divided into blocks containing a fixed 
number of bytes. The contents of a file are divided into block-sized segments, 
and stored in a series of blocks that are not necessarily consecutive. 

The file system associates each file with an inode, which is a data structure 
that contains information about the file, including the file size and which blocks 
contain the file data. Unlike actual UNIX file systems, the inodes in our system 
do not contain other information such as access privileges and time stamps. 

There is only one directory, the root directory, which maps file names to inode 
numbers. No two file names can refer to the same file, so no two file identifiers can 
map to the same inode number. We also assume that the disk is unbounded—the 
file system has access to an infinite number of inodes and blocks. 

To read a byte from a given file, the file system first looks up the file name in 
the root directory, and obtains the number of the corresponding inode. Assuming 
the file exists, the file system then looks up the inode. From the information in 
the inode, the file system determines if it is reading a byte that is within the 
bounds of the file size, and if so, which block contains the relevant byte. Finally, 
the file system reads the byte from that block and returns the value read. 

A similar look-up process occurs when writing a byte in a file. In this case, 
if the file system is writing a byte that is within the bounds of the existing file 
size, it simply stores the new value to the appropriate byte. Otherwise, the file 
system extends the file up to the index of the byte it is writing. It then stores 


4 Arkoudas, Zee, Kuncak, Rinard 


the appropriate value to the byte it is writing, and a default pad value to the 
bytes in between. 

Our formalization consists of a set of axioms in first-order logic with sorts, 
polymorphism, and structural induction. We use generic Athena libraries that 
contain axiomatizations of natural numbers, value options, finite maps, and re- 
sizable arrays; see the Appendix for a brief description of those libraries. 


3 Abstract specification of the file system 


Our specification is an abstract model of the file system that hides the com- 
plexity of data structures such as inodes and data blocks by representing files as 
indexable sequences of bytes. 

The specification uses the following sorts (the first two are introduced as new 
primitive domains, while the latter two are defined as sort abbreviations): 


sorts Byte, FileID 
define File = RSArrayOf (Byte) 
define AbState = FMap(FileID, File) 


The sort Byte is an abstract type whose values represent the units of file content. 
FileID is also an abstract type; its values represent file identifiers. We define File 
as a resizable array of Byte. The abstract state of the file system, AbState, is 
represented as a finite map from file identifiers (FileID) to file contents (File). 
We also introduce a distinguished element of Byte, called fiullByte, which is used 
to pad a file in the case of an attempt to write at a position exceeding the file 
size: declare fillByte : Byte. 


3.1 Specification of the abstract read operation 
We begin by giving the signature of the abstract read operation, absRead: 
declare absRead : FileID x Nat x AbState > ReadResult 


Thus absRead takes a file identifier fid, an index 7 in the file, and an abstract 
file system state s; and returns an element of ReadResult. The latter is defined 
as the following datatype: 


datatype ReadResult = EOF 
| Ok( Byte) 
| FileNotFound 


Therefore, the result of any absRead operation is one of three things: FOF, if 
the index is out of bounds; FileNotFound, if the file does not exist; or, if all 
goes well, a value of the form Ok(v) for some byte v, representing the content of 
file fid at position 2. More precisely, the semantics of absRead are given by the 
following three axioms: 
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[AR1] V fid i s. lookUp (fid, s) = NONE => read(fid, i, s) = FileNotFound 
[AR2] V fid i s file . {lookUp (fid, s) = SOME(file) \ arrayLen(file) < i] => 
read(fid,i,s) = EOF 
[ARs] V fidis v file . [lookUp (fid, s) = SOME(file) \ arrayRead (file,1) = SOME(v)| 
=> read(fid,i,s) = Ok(v) 


Using the equality conditions for finite maps and resizable arrays, we are able 
to prove the following extensionality theorem for abstract states: 


V 81 82.8, = 8 &|V fid i. read(fid, 1, 51) = read(fid, i, s2)]. (1) 


3.2 Specification of the abstract write operation 


The abstract write operation has the following signature: 
declare write: FileID x Nat x Byte x AbState — AbState 


This is the operation that defines state transitions in our file system. It takes 
as arguments a file identifier fid, an index i indicating a file position, a byte v 
representing the value to be written, and a file system state s. The result is a 
new state where the contents of the file associated with fid have been updated by 
storing v at position 7. Note that if 7 exceeds the length of the file in state s, then 
in the resulting state the file will be extended to size i+1 and all newly allocated 
positions below 7 will be padded with the fillByte value. Finally, if fid does not 
correspond to a file in s, then an empty file of size i+ 1 is first created and then 
the value v is written. More precisely, we introduce the following axioms: 


[AW,] V fid i v 8. lookUp(fid, s) = NONE > 
write(fid, 1, v, 8) = update(s, fid, arrayWrite(makeArray (fillByte, i + 1), i, v, fillByte)) 
[AW2] V fid i v s file. lookUp(fid, s) = SOME(file) > 
write(fid,1,v, 8) = update(s, fid, array Write (file, 2, v, fillByte)) 


4 File system implementation 


Standard Unix file systems store the contents of each file in separate disk blocks, 
and maintain a table of structures called inodes that index those blocks and 
store various types of information about the file. Our implementation operates 
directly on the inodes and disk blocks and therefore models the operations that 
the file system performs on the disk. We omit details such as file permissions, 
dates, links, multi-layered directories, and optimizations such as caching. Some 
of these (e.g., permissions and date stamps) are orthogonal to the verification 
obligation and could be included with minimal changes to our proof, while others 
(e.g., caching) would likely introduce additional complexity. 

File data is organized in Block units. A Block is an array of blockSize bytes, 
where blockSize is a positive constant. Specifically, we model a Block as a finite 
map from natural numbers to Byte: 


define Block = FMap(Nat, Byte) 
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We also define a distinguished element of Block, called initialBlock, such that: 


Vi.t < blockSize => lookUp (i, initialBlock) = SOME(fillByte) 
Vi. blockSize < i = lookUp (i, initialBlock) = NONE 


In other words, an initialBlock consists of blockSize copies of fillByte. 
File meta-data is stored in inodes: 


datatype [Node = inode(fileSize : Nat, blockCount : Nat, blockList : FMap(Nat, Nat)) 


An INode is a datatype consisting of the file size in bytes and in blocks, and a 
list of block numbers. The list of block numbers is an array of the block numbers 
that contain the file data. We model this array as a finite map from natural 
numbers (array indices) to natural numbers (block numbers). 

The data type State represents the file system state: 


datatype State = state(inodeCount : Nat, stateBlockCount : Nat, 
inodes : FMap( Nat, INode), blocks : FMap(Nat, Block), root : FMap(FileID, Nat)) 


A State consists of a count of the inodes in use; a count of the blocks in use; an 
array of inodes; an array of blocks; and the root directory. We model the array of 
inodes as a finite map from natural numbers (array indices) to [Node (inodes). 
Likewise, we model the array of blocks as a finite map from natural numbers 
(array indices) to Block (blocks). We model the root directory as a finite map 
from FileID (file identifiers) to natural numbers (inode numbers). 

We also define initialState, a distinguished element of State, which describes 
the initial state of the file system. In the initial state, no inodes or blocks are in 
use, and the root directory is empty: 


declare initialState : State 
initialState = state(0,0, empty-map, empty-map, empty-map) 


4.1 Definition of the concrete read operation 
The concrete read operation, read, has the following signature: 
declare read : FileI[D x Nat x State — ReadResult 


The read! operation takes a file identifier fid, an index i in the file, and a concrete 
file system state s, and returns an element of ReadResult. It first determines if 
fid is present in the root directory of s. If not, read returns FileNotFound. 
Otherwise, it looks up the corresponding inode. If 7 is not less than the file size, 
read returns EOF. Otherwise, read looks up the block containing the data and 
returns the relevant byte. The following axioms capture these semantics (for ease 
of presentation, we omit universal quantifiers from now on; all variables can be 
assumed to be universally quantified): 


1 Ags a convention, we use bold italic font to indicate the abstract-state version of 
something: e.g., abstract read vs. concrete read, an abstract state s vs. a concrete 
state s, etc. 
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[CRi] lookUp (fid, root(s)) = NONE = read(fid, i, s) = FileNotFound 
[CR2] [lookUp (fid, root(s)) = SOME(n) A 
lookUp (n, inodes(s)) = SOME (inode( fs, bc, bl)) A (fs < i)] > read(fid,i,s) = EOF 
[CR3] [lookUp (fid, root(s)) = SOME(n) A 
lookUp (n, inodes(s)) = SOME (inode( fs, bc, bl)) \ (4 < fs) A 
lookUp (i div blockSize, bl) = SOME(bn) A lookUp (bn, blocks(s)) = SOME(block) A 
lookUp (i mod block Size, block) = SOME(v)] => read(fid, i, s) = Ok(v) 


4.2 Definition of the concrete write operation 


The concrete write operation, write, takes a file identifier fid, a byte index 7, the 
byte value v to write, and a state s, and returns the updated state: 


declare write : FileID x Nat x Byte x State — State 
[CW] lookUp (fid, root(s)) = SOME(n) => write(fid, i, v,s) = writeExisting(n, i, v, s) 
[CW] let s’ = allocINode(fid, s) in 
[look Up (fid, root(s)) = NONE A lookUp (fid, root(s’)) = SOME(n)] > 
write(fid,i,v,s) = writeEzisting(n, i, v, s’) 


If the file associated with fid already exists, write delegates the write to the helper 
function writeExisting. If the file does not exist, write first invokes allocINode, 
which creates a new, empty file, then calls writeExisting with the inode number 
of the new file. 

allocINode takes a file identifier fid and a state s, and returns an updated 
state: 


declare allocINode : FileID x State — State 
getNextINode(s) = state(inc + 1, bc, inm, bm, root) > 
allocINode(fid, s) = state(inc + 1, bc, inm, bm, update (root, fid, inc)) 


alloc[INode creates a new inode by invoking getNextINode, then associates fid 
with the new inode. 

getNextINode takes a state and returns an updated state. It allocates and 
initializes a new inode: 


declare getNextINode : State — State 
getNext Node (state (inc, bc, inm, bm, root)) = 
state(inc + 1, bc, update(inm, inc, inode(0, 0, empty-map)), bm, root) 


writeExisting takes an inode number n, a byte index 7, the byte value v to 
write, and a state s, and returns the updated state: 


declare writeExisting : Nat x Nat x Byte x State — State 

WE\] [lookUp (n, inodes(s)) = SOME (inode) A 

(i div blockSize) < blockCount (inode) \i < fileSize(inode)] => 

writeExisting(n,1,v, 8) = writeNoExtend(n, 1, v, ) 

WE2] [lookUp (n, inodes(s)) = SOME (inode) A 

(i div blockSize) < blockCount (inode) A fileSize(inode) < i] => 

writeExisting(n,1,v,s) = writeSmallExtend(n, i, v, 8) 

WE3] [lookUp (n, inodes(s)) = SOME (inode) A 
blockCount (inode) < (i div blockSize)| > 

writeExisting(n, i, v, s) = writeNoEztend(n, i, v, ectendFile(n, i, s)) 
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If 2 is less than the file size, writeExisting delegates the writing to writeNoExtend, 
which stores the value v in the appropriate location. If i is not less than the 
file size but is located in the last block of the file, writeExisting delegates to 
writeSmallExtend, which stores the value v in the appropriate position and up- 
dates the file size. Otherwise, writeExisting first invokes extendFile, which ex- 
tends the file by the appropriate number of blocks, and then calls writeNoEztend 
on the updated state. 

writeNoExtend takes an inode number n, a byte index 7, the byte value v to 
write, and a state s, and returns the updated state after writing v at index 7: 


declare writeNoExtend : Nat x Nat x Byte x State — State 
[lookUp (n, inodes(s)) = SOME(inode) A 
lookUp (4 div blockSize, blockList(inode)) = SOME(bn) A 
lookUp (bn, blocks(s)) = SOME (block)] > 
writeNoExtend(n, i, v,s) = updateStateBM (s, bn, update(block,i mod blockSize, v)) 


writeNoExtend uses the helper function updateStateBM. The function 
updateStateBM takes the state, the block number bn, and the block block, and 
returns an updated state where bn maps to block: 


declare updateStateBM : State x Nat x Block — State 
updateStateBM (state(inc, bc, inm, bm, root), bn, block) = 
state(inc, bc, inm, update (bm, bn, block), root) 


writeSmallExtend takes an inode number n, a byte index 7, the byte value v 
to write, and a state. It updates the file size and writes the byte value v at byte 
index 7 for the file associated with the inode number n, and returns the updated 
state: 


declare writeSmallExtend : Nat x Nat x Byte x State — State 
[look Up (n, inm) = SOME (inode(f s, bc, bl)) A 
lookUp (i div blockSize, bl) = SOME(bn) A 
lookUp (bn, bm) = SOME (block) A fs <i] > 
writeSmallExtend(n, i, v, state(snc, sbc,inm, bm, root)) = 
state(snc, sbc, update (inm, n, inode(i + 1, be, bl)), 
update(bm, bn, update(block,i mod blockSize,v)), root) 


extendFile takes an inode number n, the byte index of the write, and the 
state s. It delegates the task of allocating the necessary blocks to allocBlocks: 


declare extendFile : Nat x Nat x State — State 
[lookUp (n, inodes(s)) = SOME (inode) A blockCount (inode) < (j div blockSize)| > 
extendFile(n, j, s) = allocBlocks(n, (j div blockSize) — blockCount (inode) + 1, j, s) 


allocBlocks takes an inode number n, the number of blocks to allocate, the 
byte index 7, and the state s. We define it by primitive recursion: 


declare allocBlocks : Nat x Nat x Nat x State — State 
[AB,] allocBlocks(n,0,j, 8) = s 
[AB2] [getNextBlock(s) = state(inc, bc + 1,inm, bm, root) A 
lookUp (n,inm) = SOME (inode( fs, inbc, inbl))] => 
allocBlocks(n,k + 1,7, 8) = allocBlocks(n, k, j, state(inc, be + 1, 
update(inm,n, inode(j + 1, inbe + 1, update (inbl, inbc, bc))), bm, root)) 
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write 
allocINode 
write xisting 


getNextI Node 


writeNoExtend writeSmallExtend extendFile 


updateStateBM allocBlocks 


getNextBlock 


Fig. 1. The call graph of write. 


allocBlocks uses the helper function getNextBlock, which takes the state s, allo- 
cates and initializes the next free block, and returns the updated state: 


declare getNextBlock : State — State 
getNextBlock(state(inc, bc, inm, bm, root)) = 
state(inc, be + 1, inm, update(bm, bc, initial Block), root) 


The call graph summarizing the write operation is shown in Figure 1. This 
call graph largely determines the auxiliary lemmas that need to be established 
every time we wish to prove a result about write. That is, whenever we need 
to prove a result LZ about write, we prove appropriate lemmas L, and L2 
about allocINode and writeExisting. In turn, LD, will rely on a lemma Ly 
about getNextINode and Lz will reference lemmas [2;, L22, and L23 about 
writeNoExtend, writeSmallExztend, and extendFile, respectively; and so on. In 
this way we obtain a lemma dependency graph for L whose structure mirrors 
that of the call graph for write. 


In what follows we will restrict our attention to reachable states, those that 
can be obtained from the initial state by some finite sequence of write operations. 
Specifically, we define a predicate reachableN (“reachable in n steps”) via two 
axioms: reachableN(s,0) = s = initialState, and 


reachableN(s,n +1) 4s" fid i v. reachableN(s’,n) \ s = write(fid,i, v, s’) 


We then set reachable(s) @ 4 n.reachableN(s,n). We will write State for the 
set of all reachable states, and we will use the symbol $ to denote a reachable 
state. Propositions of the form V---8--+-.P(.--S--+-) and d--+---+.P(--+8---) 
should be taken as abbreviations for V---s--- . reachable(s) > P(---s--+-) and 
--+s--+.reachable(s) \ P(.-+s-+--), respectively. 
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5 The correctness proof 


5.1 State abstraction and homomorphic simulation 


This section presents a correctness criterion for the implementation. The cor- 
rectness criterion is specified using an abstraction function [15] that maps the 
state of the implementation to the state of the specification. 

Consider the following binary relation A from concrete to abstract states: 


Vs s.A(s,s) & |V fid i. read(fid,i, s) = read(fid, i, s)] 


It follows directly from the extensionality principle on abstract states (1) that 
A is functional: 
Vs 81 89. A(s, $1) x A(s, S82) => 8, = 82. 


Accordingly, we postulate the existence of an abstraction function a : State > 
AbState such that: 
Vs s.a(s)=s<A(s,8). 


That is, an abstracted state a(s) has the exact same contents as s: reading any 
position of a file in one state yields the same result as reading that position of 
the file in the other state. 


FileID x Nat x State 
C™ 
t~xtixa ReadResult 


co 


FileID x Nat x AbState* 


FileID x Nat x Byte x State —U™*_. State 


1xXxtxXtxa Qa 


FileID x Nat x Byte x AbState WT... Adstate 


Fig. 2. Commuting diagrams for the read and write operations. 


A standard way of formalizing the requirement that an implementation TZ is 
faithful to a specification S is to express J and S as many-sorted algebras and 
establish a homomorphism from one to the other. In our case the two algebras 
are IT = (FileID, Nat, Byte, State: read, write) and 


S = (FileID, Nat, Byte, AbState; read, write) 


The embeddings from Z to S for the carriers File[D, Nat, and Byte are simply 
the identity functions on these domains; while the embedding from State to 
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AbState is the abstraction mapping qa. In order to prove that this translation 
yields a homomorphism we need to show that the two diagrams shown in Figure 2 
commute. Symbolically, we need to prove the following: 


Vfid iS. read(fid,i,s) = read(fid, i, a(S)) (2) 
and 
Vfid iv $.a(write(fid,i,v,8)) = write(fid,i,v,a(s)) (3) 


5.2 Proof outline 


Goal (2) follows immediately from the definition of the abstraction function a. 
For (3), since the consequent is equality between two abstract states and we 
have already proven that two abstract states s; and s2 are equal iff any abstract 
read operation yields identical results on s; and s2, we transform (3) into the 
following: 


Vfid iv % fid' j.read(fid', j, a(write(fid, i,v,$))) = read(fid’, j, write(fid, i, v, a(3))) 
Finally, using (2) on the above gives: 
V fid fid' i j v S$. read(fid' , j, write(fid,i,v,)) = read(fid’, j, write(fid, i, v, a(3))) 


Therefore, choosing arbitrary fid, fid',j,v,i, and 3, we need to show L = R, 
where L = read(fid' ,i, write(fid, j,v,8)) and 


R= read(fid’ ,i, write(fid, j, v,a(8))) 


Showing L = R is the main goal of the proof. We proceed by a case analysis 
as shown in Fig. 3. The decision tree of Fig. 3 has the following property: if the 
conditions that appear on a path from the root of the tree to an internal node u 
are all true, then the conditions at the children of u are mutually exclusive and 
jointly exhaustive (given that certain invariants hold, as discussed in Section 6). 
There are ultimately eight distinct cases to be considered, C, through Cs, ap- 
pearing at the leaves of the tree. Exactly one of those eight cases must be true 
for any given fid, fid’,j,v,8 and i. We prove that L = R in all eight cases. 

For each case C;, 1 = 1,...,8, we formulate and prove a pair of lemmas MV; 
and M; that facilitate the proof of the goal L = R. Specifically, for each case C; 
there are two possibilities: 


1. L = R follows because both LZ and R reduce to a common term t, with L = t 
following by virtue of lemma M; and R = t following by virtue of lemma 


M;: 
L R 
t 


2. The desired identity follows because L and R respectively reduce to 
read(fid',i,8) and read(fid',i,a(S)), which are equal owing to (2). In this 
case, M; is used to show L = read(fid',i,s) and M; is used to show 
R= read(fid',i, a(8)): 
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fid' = fid fd’ # fid 
fay 
ia 
lookUp (fid, root(s)) = NONE lookUp(fid, root(s)) = SOME(n) A 
ar lookUp (n, inodes(8)) = SOME(inode(fs, be, bl)) 


Fig. 3. Case analysis for proving the correctness of write. 


L R 
M™., Ms 
read(fid',i,$)= read(fid’, i, a(3)) 
by (2) 

The eight pairs of lemmas are shown in Figure 4. The “abstract-state” ver- 
sions of the lemmas ({[Mj],i = 1,...,8) are readily proved with the aid of Vam- 
pire from the axiomatizations of maps, resizable arrays, options, natural num- 
bers, etc., and the specification axioms. The concrete lemmas M; are much more 
challenging. 


6 Reachability invariants 


Reachable states have a number of properties that make them “well behaved.” 
For instance, if a file identifier is bound in the root of a state s to some inode 
number n, then we expect n to be bound in the mapping inodes(s). While this 
is not true for arbitrary states s, it is true for reachable states. In what follows, 
by a state invariant we will mean a unary predicate on states I(s) that is true 
for all reachable states, i.e., such that Vs. I(s). 
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read (fid, 1, write( fid, i,v,)) = Ok(v) 
read(fid, i, write( fid, 1, v, s) = Ok(v) 


[look Up (fid, root(s)) = NONE Ni < j] > read(fid, 1, write(fid, j,v,8)) = Ok(v) 
[look Up (fid, s) = NONE Ni < j| > read(fid, i, write( fid, j,v, s)) = Ok(v) 


[look Up (fid, root(s)) = NONE A j < i] > read(fid, i, write(fid, j,v,8)) = 
[look Up (fid, s) = NONE A j < i] > read(fid, i, write( fid, j,v, s)) = EOF 


[lookUp (fid, root(S)) = SOME(n) A 
lookUp (n, inodes(S)) = SOME (inode(fs, bc, bl)) At AJ AZ < fs] > 
read(fid, i, write(fid, j, v,8)) = read(fid, i, 8) 
[look Up (fid, s) = SOME(A) Ai #9 Aj < arrayLen(A)] > 
read(fid, i, write(fid, j, v, s)) = read(fid, i, s) 


[look Up (fid, root(S)) = SOME(n) A 
lookUp (n, inodes(S)) = SOME (inode(fs, bc, bl)) A fs <j At < fs] > 
read(fid, 1, write(fid, j,v,8)) = read (fid, i, 8) 
[look Up (fid, s) = SOME(A) A arrayLen(A) < j Ai < arrayLen(A)| > 
read(fid,i, write(fid, j, v, s)) = read(fid, i, s) 


[look Up (fid, root(S)) = SOME(n) A 

lookUp (n, inodes(S)) = SOME (inode(fs, bc, bl)) A fs <tAti< j] => 
read (fid,1, write( fid, j, v,8)) = Ok(fillByte) 
[look Up (fid, s) = SOME(A) A arrayLen(A) < j A arrayLen(A) <iAi <j] => 
read(fid, i, write(fid, j,v, s)) = Ok(fillByte) 

[look Up (fid, root($)) = SOME(n) A 
lookUp (n, inodes(S)) = SOME (inode(fs, bc, bl)) A fs <j AI <> 

read(fid, i, write(fid, j,v,$)) = EOF 
[look Up (fid, s) = SOME(A) A arrayLen(A) < j A arrayLen(A) <iAj <i> 

read(fid,i, write(fid, j, v, s)) = EOF 

fid, F fidy => read (fidy, i, write(fidi, j,v,8)) = read(fidy, 1, 3) 
fid: & fidy > read(fid,, i, write(fid,,j,v,s)) = read(fid,, i, s) 


Fig. 4. Main lemmas 


There are 12 invariants invp,...,inv1,, that are of particular interest. The 
proof relies on them explicitly, i-e., at various points in the course of the argument 
we assume that all reachable states have these properties. Therefore, for the 
proof to be complete, we need to discharge these assumptions by proving that 
the properties in question are indeed invariants. 

The process of guessing useful invariants—and then, more importantly, try- 
ing to prove them—was very helpful in strengthening our understanding of the 
implementation. More than once we conjectured false invariants, properties that 
appeared reasonable at first glance but later, when we tried to prove them, 
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turned out to be false. For instance, a seemingly sensible “size invariant” is that 
for every inode of size fs and block count bc we have 


fs = [(be — 1) - blockSize] + (fs mod blockSize) 


But this equality does not hold when the file size is a multiple of the block count. 
The proper invariant is ? 


[fs mod blockSize = 0 => fs = bc - blockSize] A 
[fs mod blockSize £ 0 => fs = ((bc — 1) - blockSize) + (fs mod blockSize)] 


where div denotes integer division. For any inode of file size fs and block count 
bc, we will write szInu(fs, bc) to indicate that fs and bc are related as shown by 
the above formula. 

Figure 5 presents the twelve reachability invariants for our file system imple- 
mentation. In the sequel we focus on the first four invariants, inv inv, ,inve,invs. 
These four invariants are fundamental and must be established before anything 
non-trivial can be proven about the system. They are also co-dependent, mean- 
ing that in order to prove that an operation preserves one of them, say invj;, 
we often need to assume that the incoming state not only has inv; but also one 
or more of the other three invariants. For instance, we cannot prove that write 
preserves invs, i.e., that 


Viv s. inu3(s) = inv3(write(fid, t, v, s)) 


unless we also assume that s has invp. Or suppose we want to prove that 
writeExisting preserves any of the four invariants, say invp, so that our goal 
is to show inup(writeExisting(n, i, v,s)) on the assumptions 


lookUp (n, inodes(s)) = SOME (inode(fs, bc, bl)) (4) 


and 
inuo(s) (5) 


Consider the case 
be <i div blockSize, 


whereby writeExisting(n,i,v, 8) returns 
writeNoExtend(n, 1, v, extendFile(n, i, s)). 


Since writeNoExtend is conditionally defined, we need to show that its three 
preconditions are satisfied in the intermediate state s1 = ertendFile(n, i, s). It 
is easy enough to show that the first precondition holds, i.e., that 


lookUp (n, inodes(s1)) = SOME (inode(fs1, bc1, bl1)) 


for some fs,,bc1, and 611; this follows from (4) and an auxiliary lemma stat- 
ing that extendFile preserves the invariant I(s) = inDom(n, inodes(s)) (for 


? This invariant is equivalent to be = (fs + blockSize — 1) div blockSize. 
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[lookUp (fid, root(s)) = SOME(n)] => inDom(n, inodes(s)) 


: [lookUp (n, inodes(s)) = SOME (inode(fs, bc, bl))| > 
[inDom(k, bl) &k < bc] 


: [ lookUp (n, inodes(s)) = SOME (inode) A 
lookUp (bn, blockList(inode)) = SOME(bn‘)] => 
inDom(bn’, blocks(s)) 


: [lookUp (n, inodes(s)) = SOME (inode(fs, bc, bl))] = szInv(fs, bc) 
: inDom(bnum, blocks(s)) = bnum < stateBlockCount(s) 


: inDom(nodeNum, inodes(s)) <= nodeNum < inodeCount(s) 


: [lookUp (nodeNum, inodes(s)) = SOME(inode(fs, bc, bl)) A bc = 0] 


=>fs=0 

: [fid, # fid, A 

lookUp (fid,, root(s)) = SOME(nodeNum1) A 

lookUp (fidy, root(s)) = SOME(nodeNum2)| 
=> nodeNum, # nodeNum2 


: [lookUp (nodeNum, inodes(s)) = SOME(node) A 

lookUp (k, blockList(node)) = SOME(bnum) A 

lookUp (bnum, blocks(s)) = SOME(block)| => 
(inDom(j, block) = 7 < blockSize) 


: [lookUp (nodeNum1, inodes(s)) = SOME(node1) A 
lookUp (nodeNumz2, inodes(s)) = SOME(node2) A 
look Up (k1, blockList(node1)) = SOME(bnum1) A 
look Up (ka, blockList(node2)) = SOME(bnumz2) A 
nodeNum, 4 nodeNum2| 

=> bnum, 4 bnume 


= 
= 


: [lookUp (nodeNum, inodes(s)) = SOME(node) A 
look Up (k1, blockList(node)) = SOME(bnum1) A 
look Up (ka, blockList(node)) = SOME(bnum2) A 
ki # ke] 

=> bnum, 4 bnume 


: [lookUp (nodeNum, inodes(s)) = SOME(inode(fs, bc, bl)) A 
i div blockSize < bc A fs <iA 

lookUp (4 div blockSize, bl) = SOME(bnum) A 

lookUp (bnum, blocks(s)) = SOME(block)| => 

lookUp (i mod blockSize, block) = SOME(fillByte) 


Fig. 5. Reachability Invariants 
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fixed inode number n). However, it is more challenging to show that the two 
remaining preconditions hold, i.e., that there exist bn, and block, such that 
lookUp (i div blockSize, bl) = SOME(bn,) and 


lookUp (bn4, blocks(s1)) = SOME (block). 


But these would follow immediately if we could show that s; has inv, and inv 
and that i div blockSize < bc,. Showing that s, has inv, and invg would also 
follow immediately if we strengthened our initial hypothesis (5) by additionally 
assuming that s has inv, and inv2, provided we have shown elsewhere that 
ertendFile preserves both of these invariants. However, showing i div blockSize < 
bc, presupposes that s; has invz3. Consequently, we are led to assume that the 
original state s has all four invariants. Provided we have already shown that 
extendFile preserves each of the four invariants, it then follows that s; has all 
four of them, and hence that the preconditions of writeNoEztend hold. 


6.1 Proving invariants 
Showing that a unary state property I(s) is an invariant proceeds in two steps: 


1. proving that I holds for the initial state, I(s9); and 
2. proving V fid i v s.I(s) > I(write(fid, 1, v, s)). 


Once both of these have been established, a routine induction on n will show 
that 
Vn s.reachableN(s,n) = I(s). 


It then follows directly by the definition of reachability that all reachable states 
have I. 

Proving that the initial state has an invariant inv; is straightforward: in 
all twelve cases it is done automatically. The second step, proving that write 
preserves inv;, is more involved. Including write, the implementation comprises 
ten state-transforming operations,* and control may flow from write to any one of 
them. Accordingly, we need to show that all ten operations preserve the invariant 
under consideration. This means that for a total of ten operations fo,..., fo and 
twelve invariants inup,..., inv1,, we need to prove 120 lemmas, each stating that 
fi preserves inv;. 

Most of the operations f; are defined conditionally, in the form 


Vai yi. PC, (xi, yi) > files) =--- 


where x;, y; are lists of distinct variables; PC;(x;,y;), the “precondition” of 
fi, is usually a conjunction of equations in the variables a; and y; (if f; is not 
defined conditionally then this can be regarded as the empty conjunction, i.e., 


3 By a “state-transforming operation” we mean one that takes a state as an argument 
and produces a state as output. There are ten such operations, nine of which are 
auxiliary functions (such as extendFile) invoked by write. 


Verifying a file system implementation 17 


as the constant true). Therefore, each of the 120 invariant-preservation lemmas 
is of the form 


Vay ys 8-[PCi(ai, yi) A 1(s)] = ino; (fi(@i)) (6) 


fori =0,...,9 and 7 =0,...,11, and where I(s) is of the form inv,(s) A inv, A 
+++ A inu;, where k > 0 and i, € {0,1,...,11} for l <r<k. 

The large majority of the proof text (about 80% of it) is devoted to proving 
these lemmas. Some of them are surprisingly tricky to prove, and even those that 
are not particularly conceptually demanding can be challenging to manipulate, 
if for no other reason simply because of their volume. Given the size of the func- 
tion preconditions and the size of the invariants (especially in those cases where 
we need to consider the conjunction of several invariants at once), an invariance 
lemma can span multiple pages of text. Proof goals of that scale test the limits 
even of cutting-edge ATPs. For instance, in the case of a proposition P that 
was several pages long (which arose in the proof of one of the invariance lem- 
mas), Spass took over 10 minutes to prove the trivial goal P => P’, where P’ was 
simply an alphabetically renamed copy of P (Vampire was not able to prove it 
at all, at least within 20 minutes). Heavily skolemizing the formula and blindly 
following the resolution procedure prevented these systems from recognizing the 
goal as trivial. By contrast, using Athena’s native inference rules, the goal was 
derived instantaneously via the two-line deduction assume P in claim P’, be- 
cause Athena treats alphabetically equivalent propositions as identical and has 
an efficient implementation of proposition look-ups. This speaks to the need 
to have a variety of reasoning mechanisms available in a uniform, integrated 
framework. 

There are many additional lemmas that were used in proving the invariants 
or in proving other results after all twelve invariants had already been proven. 
We mention two typical ones: 


Lemma 1. [f fid, 4 fid, and 
look Up (fidy, root(s)) = x 
then lookUp (fidg, root(write(fid,,1,v,8))) =x. 
Lemma 2. If lookUp (n, inodes(s)) = SOME (inode) and 
lookUp (n, inodes(allocBlocks(n, k, 7, 8))) = SOME (inodeg) 


then blockCount(inode2) = blockCount (inode) + k. 


7 Proof automation with tactics 


After proving a few invariance lemmas for some of the operations it became 
apparent that a large portion of the reasoning was the same in every case and 
could thus be factored away for reuse. 
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Athena makes it easy to abstract concrete proofs into natural-deduction proof 
algorithms called methods. For every state-transforming operation f; we wrote a 
“preserver” method P; that takes an arbitrary invariant J as input (expressed as 
a unary function that takes a state and constructs an appropriate proposition) 
and attempts to prove the corresponding invariance lemma. 


Vai yi 8. [PCi(@i, ys) A 1(s)] > T(fi(ai)) (7) 


P,; encapsulates all the generic reasoning involved in proving invariants for f;. If 
any non-generic reasoning (specific to I) is additionally required, it is packaged 
into a proof continuation K and passed into P; as a higher-order method argu- 
ment. P; can then invoke K at appropriate points within its body as needed. Sim- 
ilar methods for other functions made the overall proof substantially shorter— 
and easier to develop and to debug—than it would have been otherwise. 

Consider, for example, proving that allocBlocks preserves a certain property 
I. This is always done by induction on k, the number of blocks to be allocated. 
Performing the base inductive step automatically, managing the inductive hy- 
pothesis, proving that the relevant precondition involving getNextBlock is satis- 
fied in the context in which allocBlocks is called, deriving useful consequences 
of that fact, etc., these are all standard tasks that are repetitively performed 
regardless of I; we have abstracted all of them away in a higher-order method 
that accepts the [-specific reasoning as an input method. 

Proof programmability was useful in streamlining several other recurring pat- 
terns of reasoning, apart from dealing with invariants. A typical example is this: 
given a reachable state $, an inode number n such that lookUp (n, inodes(s)) = 
SOME (inode(fs, bc, bl)), and an index i < fs, we often need to prove the exis- 
tence of bn and block such that lookUp (i div blockSize, bl) = SOME(bn) and 


look Up (bn, blocks(s)) = SOME (block) 


The reasoning runs as follows: first, from the reachability of 5, we infer that 
it has certain invariants, including invg, inv, inva, and inv3. From these in- 
variants, the assumption i < fs, and standard arithmetic laws we may deduce 
(i div blockSize) < bc. From this, our initial assumptions, and inv;, we conclude 
that i div blockSize is in the domain of the mapping bl. Thus the existence of 
an appropriate bn is ensured, and along with it, owing to invo, the existence 
of an appropriate block. We packaged this reasoning in a method find-bn-block 
that takes all the relevant quantities as inputs, assumes that the appropriate 
hypotheses are in the assumption base, and performs the appropriate inferences. 
The method also accepts a proof continuation K that is invoked once the goal 
has been successfully derived. 

Another example is a_ slight extension of this method, named 
find-bn-block-val, that operates under the same assumptions but, in addi- 
tion to a block number and the block itself, yields a value v such that 
lookUp (i mod blockSize, block) = SOME(v), which is possible because 
i mod blockSize <  blockSize. Yet another example of a streamlined proof 
method is an inductive method showing that an invariant holds for all reachable 
states. 
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8 A sample lemma proof 


In this section we will prove lemma [Mg], which can be viewed as a frame con- 
dition: it asserts that performing a write operation on a given file leaves the 
contents of every other file unchanged. More specifically, let fid, refer to the 
file to be written, let fid, be any file identifier distinct from fid,, let s be any 
reachable state, and let s’ be the state obtained from s by writing some value 
into some byte position of fid,. Then [Ms] says that reading any byte of fid, in 
s’ yields the same result as reading that byte in s. 

The proof relies on four auxiliary lemmas about write, given below. Lem- 
mas (8) and (9) handle the case when fid, (the file to be written) already exists 
in s, while (10) and (11) apply to the case when fid, is unbound in the root of 
s. As usual, all the variables are assumed to be universally quantified. 


[look Up (n1, inodes(s)) = SOME(inode,) An £ ni A 
lookUp (bn, blockList(inode1)) = SOME(bn’) A 
lookUp (bn’, blocks(s)) = SOME(block1) A lookUp (fid, root(s)) = SOME(n)| = (8) 
lookUp (1, inodes(write(fid, 1, v, s))) = SOME (inode) A 
lookUp (bn’, blocks (write(fid, 1, v, s))) = SOME (block) 


[look Up (n1, inodes(s)) = SOME(inode1) An £ n1 A 
look Up (fid, root(s)) = SOME(n)| > (9) 
look Up (n1, inodes(write(fid, 1, v, s))) = SOME (inode; ) 
[lookUp (n1, inodes(s)) = SOME(inode,) A 
lookUp (bn, blockList(inode,)) = SOME(bn’) A 
lookUp (bn’, blocks(s)) = SOME(block:) A lookUp (fid, root(s)) = NONE|= (10) 
look Up (n1, inodes(write(fid, 1, v, s))) = SOME (inode) A 
lookUp (bn’, blocks (write (fid, i, v, s))) = SOME(block;) 
[look Up (n1, inodes(s)) = SOME(inode) A lookUp (fid, root(s)) = NONE] => (11) 
lookUp (n1, inodes(write(fid, i,v, s))) = SOME (inode:) 


In turn, each of the above four lemmas about write relies on a number of other 
lemmas about the various operations in the call graph of write (see the relevant 
remarks in Section 4). We will state those lemmas after we present the proof of 
[Ms]. 

We next present a natural-deduction style proof of [Mg] to give the reader 
an idea of the abstraction level at which Athena proofs are written. We believe 
that the said level is roughly equivalent to the level at which a formally trained 
computer scientist would communicate the proof to another computer scientist of 
a similar background. The proof is rigorous and thorough, but does not descend 
to the level of primitive inference rules (such as introduction and elimination 
rules for the logical connectives or congruence rules for equality); the applications 
of such rules are fairly tedious steps that are filled in by Vampire. The overall 
proof is guided by constructs such as “pick any ---”, “assume that such and 
such holds”, “we distinguish two cases”, “from P,, P2 and P3 we infer P”, and 
so on. 

The proof of [Ms] is given below in English, but the level of detail and the 
overall structure of the argument are isomorphic to those of the formal Athena 
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deduction (for instance, the formal Athena proof runs to 120 lines, whereas the 
English proof below is about 64 lines). 


Lemma 38 ([Mg]). Jf fid, # fidy then read(fidy,i, write(fid,,j,v,s)) = 
read(fid,, 1,8). 


Proof. Pick arbitrary fid,, fidy,i,7,v, and $, and suppose that 
fid, # fidg. i) 
We will prove the goal 
read(fidy,1, write(fid,,j,v,8)) = read(fidy,i,8) (13) 


by distinguishing two (mutually exclusive and jointly exhaustive) cases: 


lookUp (fid,, root(s)) = NONE (14) 
and 
4 nz. lookUp (fidy, root(s)) = SOME(n2). (15) 


If fid is unbound in root(s) (case (14)), then, by the definition of read, we have 
read (fid,i,8) = FileNotFound. (16) 
By Lemma 1, (12), (14), and the reachability of $ we conclude 
lookUp (fid,, root (write(fid,,7,v,$))) = NONE (17) 
and therefore again by the definition of read we infer 
read(fidy,1, write(fid,,j,v,)) = FileNotFound (18) 
and hence (13) follows from (16) and (18). We now consider case (15), whereby 
look Up (fidy, root($)) = SOME(n2) (19) 
for some inode number ng. Since 3 is reachable, it has invp, so that 
lookUp (na, inodes(s)) = SOME (inode(fsz, bc2, bl2)) (20) 


for some fs, bc2, and blz. Moreover, we note that by Lemma 1, (19), (12), and 
the reachability of s, we have 


lookUp (fid,, root (write (fid,,j,v, 8))) = SOME(na). (21) 


We proceed by distinguishing two cases, i < fs. and fs, < 7. Suppose first 
that i < fs,. In that case it becomes evident by inspection that all the precon- 
ditions of method find-bn-block-val are satisfied: $ has the required invariants 
because it is reachable; ng is mapped by the inode mapping of 5 to the inode 
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comprising fs., beg, and bl2; and i < fs,. Therefore, we are able to prove that 
there exist bn2, block2, and v2 such that 


lookUp (i. div blockSize, blz) = SOME(bn2) (22) 
lookUp (bna, blocks($)) = SOME (block2) (23) 

and 
lookUp (i mod blockSize, blockz) = SOME (v2). (24) 


It now follows from (19), (20), the assumption 7 < fs5, (22), (23), (24), and the 
definition of read that 
read(fidy,1,8) = Ok(v2) (25) 


and therefore our goal (13) becomes reduced to proving 
read(fidy, i, write(fid,,j,v,8)) = Ok(ve2). (26) 


We establish (26) by considering two subcases. First, suppose that fid, is 
unbound in the root of 8, i.e., 


lookUp (fid,, root(s)) = NONE. (27) 
Then by (27), (20), (22), (23), the reachability of s and Lemma (10), we conclude 


lookUp (ng, inodes(write(fid,,7,v,8))) = 


SOME (inode(fsy, bc2, bl2)) 28) 
and 
lookUp (bna, blocks (write(fid,,j,v,8))) = SOME(block2). (29) 


Accordingly, by the definition of read, (21), (28), the assumption i < fs5, (22), 
(29), and (24), we obtain the desired (26). 
Now suppose, by contrast, that 


lookUp (fid,, root(s)) = SOME(n,) (30) 


for some inode number nj. Since $ is reachable, it has the invariant inv7, so from 
(30), (19), and (12) we conclude 


Ny x ng. (31) 


From (8), the reachability of $, (20), (31), (22), (23), and (30) we can now again 
derive (28) and (29). Hence, by the definition of read, (21), (28), the assumption 
i < fs, (22), (29), and (24) we obtain (26). 

We finally consider the possibility fs. <7. In that case the definition of read 
in tandem with (19) and (20) entails 


read(fidy,1,8) = EOF. (32) 


As before, we again distinguish two subcases, according to whether or not fid, 
is bound in the root of S, and we use lemmas (9) and (11), respectively, to infer 


22 Arkoudas, Zee, Kuncak, Rinard 


(28). In combination with (21), it follows from the definition of read that in 
either case we have 


read(fidy,1, write(fidy, j,v,$)) = EOF (33) 


and the desired equality now follows from (32) and (33). This completes our case 
analysis and the proof. 


Finally, we list below the remaining lemmas needed for lemmas (8), (9), 
(10), and (11). 


writeSmallEztendPreservesINodeAndBlockMaps: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ nt A 
lookUp (k, blockList(inode,)) = SOME(bni) A 
lookUp (bn1, blocks(s)) = SOME (block) A inv10(s) 
look Up (n, inodes(s)) = SOME (inode(fs, bc, bl)) A 
lookUp (4 div blockSize, bl) = SOME(bn) A 
lookUp (bn, blocks(s)) = SOME(block) A fs < i] > 
lookUp (n1, inodes(writeSmallExtend(n, i, v, s))) = SOME (inode) A 
lookUp (bni, blocks (writeSmallEztend(n, i, v, s))) = SOME (block1) 


writeSmallExtendPreserves[NodeMap: 
[look Up (n1, inodes(s)) = SOME(inode,) An # ni A 
look Up (n, inodes(s)) = SOME (inode(fs, bc, bl)) A 
lookUp (4 div blockSize, bl) = SOME(bn) A 
lookUp (bn, blocks(s)) = SOME(block) A fs < i] > 
lookUp (n1, inodes(writeSmallExtend(n,i,v,s))) = SOME (inode:) 


2 


writeNoEartendPreservesINodeAndBlockMaps: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ ni A 
look Up (k, blockList(inode,)) = SOME(bni) A 
lookUp (bn1, blocks(s)) = SOME (block) A inv10(s) 
look Up (n, inodes(s)) = SOME (inode) A 
lookUp (4 div blockSize, blockList(inode)) = SOME(bn) A 
lookUp (bn, blocks(s)) = SOME(block)] > 
look Up (n1, inodes(writeNoExtend(n,i,v,s))) = SOME(inode1) A 
lookUp (bn1, blocks (writeNoExtend(n, i, v,s))) = SOME(block,) 


Go 


writeNoExtendPreservesINodeMap: 
[look Up (n1, inodes(s)) = SOME(inode,) An ni A 
lookUp (n, inodes(s)) = SOME (inode) A 
lookUp (4 div blockSize, blockList(inode)) = SOME(bn) A 
lookUp (bn, blocks(s)) = SOME(block)] > 
lookUp (n1, inodes(writeNoExtend(n,i,v,s))) = SOME (inode:) 


ce 
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allocBlocksPreservesINodeAndBlockMaps: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ n1 A 
inDom(n, inodes(s)) A inva(s) A 
lookUp (bn, blockList(inode:)) = SOME(bn’) A 
lookUp (bn’, blocks(s)) = SOME (block)| => 
lookUp (n1, inodes(allocBlocks(n, k, fs,s))) = SOME(inode1) A 
lookUp (bn’, blocks (allocBlocks(n, k, fs, s))) = SOME (block) 


allocBlocksPreservesINodeMap: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ n1 A 
inDom(n, inodes(s))] > 
lookUp (n1, inodes(allocBlocks(n, k, fs, s))) = SOME (inode, ) 


extendFilePreservesINodeAndBlockMaps: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ ni A 
inDom(n, inodes(s)) A inva(s) A 
lookUp (bn, blockList(inode,)) = SOME(bn’) A 
lookUp (bn’, blocks (s)) = SOME (block)| => 
lookUp (n1, inodes(extendFile(n, i, s))) = SOME(inode1) A 
lookUp (bn’, blocks (extendFile(n, i, ))) = SOME (block) 


extendFilePreservesI!NodeMap: 
[look Up (n1, inodes(s)) = SOME(inode,) An £ n1 A 
inDom(n, inodes(s))] => 
lookUp (n1, inodes(extendFile(n, i, s))) = SOME(inode,) 


writeExistingPreservesINodeAndBlockMaps: 
[invi(s) A inve(s) A inv3(s) A inva(s) A invio(s) 
lookUp (n1, inodes(s)) = SOME (inode) A 
n #1 A lookUp (bn, blockList(inode:)) = SOME(bn’) A 
lookUp (bn’, blocks(s)) = SOME( block) A 
look Up (n, inodes(s)) = SOME (inode(fs, bc, bl))] > 
look Up (n1, inodes(writeEzisting(n, i, v, 8))) = SOME(inode1) A 
lookUp (bn’, blocks (writeExisting(n, i, v, 8))) = SOME(block1) 


writeExistingPreservesINodeMap: 
[invi(s) A inve(s) A invs(s) An A n1 
look Up (n1, inodes(s)) = SOME (inode, ) 
look Up (n, inodes(s)) = SOME (inode(fs, bc, bl))] > 
look Up (n1, inodes(writeExisting(n, it, v,s))) = SOME(inode,) 


9 Related work 


Techniques for verifying the correct use of file system interfaces expressed as finite 
state machines are presented in [9, 10,8, 2]. In this paper we have addressed the 
more difficult problem of showing that the file system implementation conforms 
to its specification. Consequently, our proof obligations are stronger and we have 
resorted to more general deductive verification. Static analysis techniques that 
handle more complex data structures include predicate abstraction and shape 
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analysis [19,18,14,6]. These approaches are promising for automating proofs 
of program properties, but have not been used so far to show full functional 
correctness, as we do here. Security properties of a Unix file system are studied 
in [23, Chapter 10]; these properties are orthogonal to the correct functioning 
of a file system for storing and reading data. A sample specification of a widely 
used file system is [1]. Simple abstract models of file systems have also been 
developed in Z [24, Chapter 15]. 

Alloy [12] is a specification language based on a first-order relational calculus 
that has been used to describe the directory structure of a file system (but 
without modelling read and write operations). The Alloy Analyzer is a model 
finder for Alloy specifications that can be used to check structural properties of 
file systems in finite scope. The use of Alloy is complementary to proofs [4]. Alloy 
is useful for debugging, whereas our proofs ensure that the refinement relation 
holds for any number of files, any file sizes, and all sequences of operations. In 
addition, readable, high-level proofs can be viewed as explanations of why the file 
system implementation is correct, and therefore provide guidance to developers 
on how to modify the system in the future while preserving its correctness. 

It is interesting to consider whether the verification burden would be lighter 
with a system such as PVS [17] or ACL2 [13] that makes heavy use of automatic 
decision procedures for combinations of first-order theories such as arrays, lists, 
linear arithmetic, etc. We note that our use of high-performance off-the-shelf 
ATPs already provides a considerable degree of automation. In our experience, 
both Vampire and Spass have proven quite effective in non-inductive reasoning 
about lists, arrays, etc., simply on the basis of first-order axiomatizations of the 
these domains. Our experience supports a recent benchmark study by Armando 
et al. [5], which showed that a state-of-the-art paramodulation-based prover with 
a fair search strategy compares favorably with CVC [7] in reasoning about arrays 
with extensionality. 


10 Conclusions 


We have presented a correctness proof for the key operations (reading and writ- 
ing) of a file system based on Unix implementations. We are not aware of any 
other file system verification attempts dealing with such strong properties as the 
simulation relation condition, for all possible sequences of file system operations 
and without a priori bounds on the number of files or their sizes. Despite the ap- 
parent simplicity of this particular specification and implementation, our proofs 
shed light on the general kinds of reasoning that would be required in estab- 
lishing full functional correctness for any file system. Our results suggest that a 
combination of state-of-the art formal methods techniques greatly facilitates the 
deductive verification of crucial software infrastructure components such as file 
systems. 

We have found Athena to be a powerful framework for carrying out a com- 
plex verification effort. Polymorphic sorts and structures allow for natural data 
modelling; strong support for structural induction facilitates inductive reasoning 
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over such datatypes; a block-structured natural deduction format helps to make 
proofs more readable and writable; a higher-order functional metalanguage and 
assumption base semantics allow for powerful trusted proof tactics; and the use 
of first-order logic allows for smooth integration with state-of-the-art first-order 
ATPs, keeping the proof steps at a high level of detail. Our use of these features 
was essential in dealing with the strong properties arising from the simulation 
relation condition, where most of the complexity stems from the details of un- 
bounded data structures. 


Acknowledgements. We thank Darko Marinov and Alexandru Salcianu for 
useful comments on an earlier version of this manuscript. 
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A Some standard Athena libraries 


A.1 Options 
Options in Athena are represented as follows: 
datatype Option(S) = NONE | SOME(S) 


Here S$ is a sort parameter. Thus Option can be viewed as a sort constructor 
that takes an arbitrary sort S and builds a new sort, Option(S). 

Datatypes in Athena are free algebras with corresponding induction princi- 
ples. For instance, the following axioms are automatically generated from the 
above definition: 


Va: Option(S).x« = NONE \V [Avu: S.% = SOME(v)| (34) 
Vu: S.NONE # SOME(v) (35) 
Vu1:S,v2:5.SOME(v1) = SOME (v2) > v1 = ve (36) 


Note that in the above axioms we annotated quantified variables with their sorts 
for readability purposes. In practice Athena uses a Hindley-Milner algorithm to 
infer the most general possible sorts of quantified variables, so such annotations 
are not necessary; we omit them in the remainder of this Appendix. 

Structural induction may be performed on datatypes using a built-in syntax 
form that Athena offers for that purpose, and which automates much of the 
tedium associated with inductive proofs (e.g., managing inductive hypotheses in 
multiply nested inductive arguments). 
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A.2 Finite maps 
Polymorphic finite maps are introduced in Athena as follows: 
structure FMap(D, R) = empty-map | update(FMap(D, R), D, R) 


Here D and R are sort parameters, representing the sorts of the domain and the 
range of the map, respectively. The declaration states that every finite map from 
D to R is either the empty-map or else it is of the form update(m, x, v), ie., it 
is an update of some other map m, obtained by binding the argument x to the 
value v (potentially overwriting whatever assignment x might have had in m). 
Like data types, structures are inductively generated: axioms of the form (34) 
are valid for structures, and induction may be performed on them. However, 
structures are not necessarily freely generated (elements are not “uniquely read- 
able”), hence Athena does not generate axioms such as (36) for structures. 
We introduce two additional useful function symbols for finite maps: 


lookUp : D x FMap(D, R) => Option(D) 
inDom : D x FMap(D, R) > Boolean 
whose semantics are captured by the following four axioms: 
[Mi] Vx. lookUp (x, empty-map) = NONE 
[M2] Vx v m.lookUp (x, update(m, x,v)) = SOME(v) 
[M3] Va yum.a2 #4 y => lookUp (a, update(m, y, v)) = lookUp (x, m) 
[Ms] Vx m.inDom(x,m) © [A v.lookUp (x,m) = SOME(v)| 


We also have an extensionality axiom for finite maps: 


[FMExt] Vimy m2. x. lookUp (a,m1) = lookUp (x, mz2)| > m1 = m2 


A.3  Resizable arrays 
Resizable arrays are inductively generated by the following structure: 


structure RSArray(S}) = makeArray(S, Nat) 
| arrayWrite(RSArray(S), Nat, S,S) 

That is, a resizable array is either of the form makeArray(x,n), which is a freshly 
constructed array of length n with the element x in every location from 0 to n—1; 
or else it is of the form arrayWrite(A,i,x, f), i.e., obtained from an already 
existing array A by writing the value zx into slot 7. If 7 happens to be outside the 
bounds of A (i.e., arrayLen(A) < i), then the length will increase to 7+ 1, the 
value x will be written into the i” position of this extended array, and all the 
other newly allocated slots will be padded with the “fill” value f. This is made 
more clear in the axioms of Figure 6. Two additional useful functions are: 


arrayLen : RSArray(S) > Nat 
arrayRead : RSArray(S') x Nat > Option(S) 


Their semantics are captured by the nine axioms [A;|—|Ag] shown in Figure 6. 
Finally, we have an extensionality axiom for arrays: 


[RSAEat] VA, Ag.[Vi.arrayRead(A,,71) = arrayRead(Az,1)| > Ai = Ao. 
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[Ai] VA n. arrayLen(makeArray(A,n)) =n 
[Ao] VAiv f.[i < arrayLen(A)] > arrayLen(arrayWrite(A,i,v, f)) = arrayLen(A) 
[A3] VA iv f.7 [i < arrayLen(A)] => arrayLen(arrayWrite(A,i,v, f)) =t1+1 
[A4] VAi.7 [i < arrayLen(A)] = arrayRead(A,i) = NONE 
[As] Va ni.i < n= arrayRead(makeArray(x,n), 1) = SOME(«) 
[Ac] VA i vu f. arrayRead(array Write(A, i, v, f),1) = SOME(v) 


[A7] VAiv f.i< arrayLen(A) => 
[Vj.t44 9 => arrayRead(arrayWrite(A, i, v, f),7) = arrayRead(A, j)] 


[As] VAiv f.3[t < arrayLen(A)] => 

[Vj -9 < arrayLen(A) => arrayRead (array Write(A, i, v, f),j) = arrayRead(A, j)| 
[Ag] VAiv f.3[t < arrayLen(A)] => 

[Vj.arrayLen(A) <j Aj <i= arrayRead (array Write(A, i, v, f), 7) = SOME(f)| 


Fig. 6. The semantics of resizable arrays 


A.4 Natural numbers 


Numeric reasoning played an important role in this project. Although no deep 
number-theoretic results were needed, it was still necessary to introduce all the 
usual arithmetic operations, including the remainder operation, and derive many 
simple results for them. We start by introducing the natural numbers as an 
algebraic datatype: 


datatype Nat = zero | succ(Nat) 


This definition automatically generates the following axioms: 


VY x.zero # succ(z) 
V x2,y.succ(#) = succ(y) > 2 =y 


Vu.x=zero V (J y.x = succ(y)) 


which are then added to the assumption base. 
Next, we introduce function symbols for the predecessor operation: 


declare pred: Nat — Nat 


as well as for (binary) addition, subtraction, multiplication, division, and re- 
mainder: 
declare +, —,*, div, mod: Nat — Nat 


We also introduce operators for numeric comparisons: 


declare <,<: Nat x Nat — Boolean 
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The semantics of these symbols are given via equational axioms (possibly 
conditionally equational axioms) that capture the usual primitive recursive defi- 
nitions of these operations. For example, predecessor is defined as a total function 
as follows: 

pred(zero) = zero \V x.pred(succ(x)) = x 


The definition of binary addition is given via the two axioms: 


Vy.zero+y=y 


V a,y.succ(x) + y = succ(z + y) 
The definitions of subtraction, multiplication, and numeric comparisons are given 
by the following axioms: 
V x.zero — x = zero 
Vu.xu—zero=2 
VY x,y.succ(x) — succ(y) = «7 — y 
V y.zero * y = zero 
Va,y.suce(xz) *y=y+(ax*y) 
Va.(a% < zero) = false 
VY x. (zero < succ(x)) = true 


V x,y. (suce(x) < succ(y)) =a <y 


The less-than-or-equal symbol is defined in terms of less-than: 
rsySr=yVa@r<y 
The definitions of quotient and remainder are as follows: 


Va. x div zero = zero 
Vajy.c<y=>u div y=zero 
Va,y.(y # zero) A(x < y) >a div y = suce((x — y) div x) 
Va. x mod zero = x 
Vayy.c<ys>u mody=2 
Vay.c<ys>u mod y=2 
Vau,y.(y #4 zero) A7A(x < y) >a mod y = (a — y) mod y 
From the above definitions, a number of useful properties can be derived, 
e.g., that addition is commutative. Most of these properties are derivable only 
with the aid of a mathematical induction principle—in our case, structural in- 
duction on the datatype Nat. Structural induction in this case corresponds to 
conventional mathematical induction on the natural numbers. Occasionally it is 
very convenient to be able to use strong induction instead, whereby one induc- 
tively assumes the truth of the statement P(n) for all m <n. For instance, the 
so-called “division algorithm” result, which states 


0< b= ((a div b) xb] + [a mod b] =a 
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can be readily proved by strong induction but is much more tedious with con- 
ventional induction. In Athena, a strong induction principle on natural numbers 
is currently formulated as a primitive method. Figure 7 depicts some numeric 
results that were needed at various points in the project. Most of them were 
proved automatically by Athena methods that mechanize induction, but a few 
of them required more detailed proofs. The reader can refer to the file nat. ath 
in the source code listing for details. 
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Fig. 7. Useful results about the natural numbers. 


